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Trading Market Design And Deployment System." 
5 FIELD OF THE INVENTION 

The present invention relates to the use of networked computer systems for the design 
and deployment of a trading market. More specifically, the invention relates to an auction engine 
organized around modular components representing dimensions of auction specifications. 

a. 

% s 

ljflj BACKGROUND OF THE INVENTION 

I j Simple auctions that do not require complex computations are currently prevalent on the 

* 1 Internet. Onsale.com, eBay.com, and Priceline.com are representative of such auctions. Onsale, 

n Inc. and Priceline, Inc. used customized software specific to their particular auction rules. This 

f j 

^ £ software is not easily modified or deployed in a different business context 
tf Toolkits embodied in software offered by Opensite and Bonsai may be used to construct 

and operate simple auctions. But customization of an auction by these tool kits is limited. For 
example, a market designer may specify the duration of the auction or select a simple auction 
format; however, other variables in establishing an auction may not be modified without 
significant labor. Although IBM has developed an auction toolkit that allows a somewhat greater 
20 degree of customization of an auction through subclassing of elements from a library of software 
objects, it is not a comprehensive market design and deployment system. Additionally, this 
system is limited to single-unit buyer-only auctions. 
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Moai, Inc. (Moai) has software that typifies products that are not auction products; 
rather, Moai provides software solutions that embody auction technology. Moai builds software 
for creating Internet auctioning solutions for manufacturers or resellers to sell surplus-goods and 
excess inventories. Although Moai's software solution may be tailored to meet the needs of a 

5 customer, the auction style and mechanism are limited to a specific auction type. 

The Michigan Internet AuctionBot, another Internet service, allows a party to create and 
manage an auction {e.g., accept bids, notify bidders of auction results, etc.). Although 
AuctionBot supports a broader set of auctions than other services, it has limitations. In 
O particular, AuctionBot cannot support activity rules of the sort encountered in industrial markets 

% :$ 

If' I 

tjt| such as the FCC spectrum auction and the California Power Exchange. Nor does it provide a 

y modular architecture for extending the range of configurability of the system. 
% 1 In sum, a market designer of an Internet auction has two options-develop software or use 

f 1 limited toolkits. Therefore, it is desirable to have a means with which to define and deploy a wide 

6 f range of Internet auction markets without engaging in lengthy software development. 
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SUMMARY OF THE INVENTION 

Methods and apparatuses for designing and deploying an interactive, real-time, universal 
trading market system on the Internet are disclosed. One embodiment of the invention relates to 
a universal auction specification system having a programmable auction server. The 
programmable auction server has a plurality of auction specification modules wherein at least one 
auction specification module corresponds to at least one function of an auction variable selected 
from the group consisting of a process bid, release information, and a clear. 

Other aspects and methods of the present invention, as well as apparatuses formed using 
these methods, are described further below in conjunction with the following figures. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 A is a system block diagram showing the components of the preferred 
embodiment. 

Figure IB is a diagram showing the programmable auction server of the system. 
5 Figures 2 and 3 schematically show one embodiment of the invention wherein a bid is 

received and is verified. 

Figure 4 shows data flow of one embodiment of the invention. 

Figure 5 illustrates a three-tier specific embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Methods and apparatuses are disclosed for designing and deploying a universal, 
interactive, real-time, trading market system serving traders communicating through the Internet 
and similar networks. This generic system for specifying and deploying trading market systems 
such as auctions is novel over the limited systems known in the art. One embodiment of the 
invention relates to a universal auction specification system having a programmable auction 
server (PAS). The programmable auction server has a plurality of auction specification modules 
wherein at least one auction specification module corresponds to at least one of the following 
auction functions: processing a bid, releasing auction information, and clearing the auction. 

In the following detailed description, numerous specific details are set forth in order to 
provide a thorough understanding of the present invention. It will be evident, however, to one of 
ordinary skill in the art that the present invention may be practiced without these specific details. 
In other instances, well known structures and devices are shown in block diagram form in order to 
avoid unnecessarily obscuring the present invention. 

Figures 1 A through IB show various embodiments of the invention in which a universal 
auction specification system of the invention may include a variety of components such as a 
Market Specification Console ("MSC") 1 10, a Universal Trading Console ("UTC") 120, a 
Universal Surveillance Console ("USC") 130, a Market Administration Console ("MAC") 150, 
PAS 140, and a communication network 160 and 161 linking various components. These 
components may be stored or operated in a single computer system or in a plurality of computer 
systems connected by a network. 



Overview of System Modules 

MSC 1 10 consists of a computer running a computer program in which a market designer 
may specify any of an infinite number of possible market protocols. Thereafter, the market 
defined by market protocols is submitted or uploaded to a PAS 140 for execution. Markets may 
5 be as simple as English or Dutch auctions with some parameters designated by a market designer. 
Alternatively, a market designer may develop an arbitrary auction that uses very complex 
computations. 

Although markets may be organized in various ways, markets generally consist of a 
*"S sequence of phases. Each phase comprises an interval(s) wherein an activity is governed by a 
MM relatively fixed set of rules specified by the market designer. The temporal flow of a market 
j: consists of a series of market phases specified by the market designer. In order to specify this 

temporal flow, the market designer must identify the phases. Phases are identified and 
) ) sequencing relations {e.g., termination conditions, conditional branching among the phases, 
1 5 etc.) are designated by manipulating representations of the phases on the Graphical User 
15 Interface (GUI) of the MSC 1 10. A phase may be defined by a time period, a limitation, a 
condition {e.g. condition precedent, condition concurrent, condition subsequent, etc.), 
exception, exclusion, or a proviso etc. The market designer may designate criteria such as 
when the phase terminates {e.g., a specified time period, condition such as the first one 
hundred bids received, etc.), the method to choose a succeeding phase (if any), and any other 
20 applicable limitations. 
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In order to specify rules such as market rules governing a particular phase, the market 
designer selects options - referred to herein as trading primitives ("TPs") - that dictate the 
behavior of components in the PAS 140. MSC 110 provides menus and other means for 
choosing options and may provide guidance to the market designer regarding legal 
combinations of these options, or recommend choices associated with specified design goals, 

UTC 120 consists of a computer running a computer program that enables a trader (e.g., 
seller, buyer, agent of a seller or buyer) to trade in any market protocol executing on the PAS 
140. UTC 120 presents information to the trader in a manner that automatically adapts to a 
specific market protocol that is executing. 

USC 130 consists of a computer running a computer program that enables a surveillance 
body such as a regulatory agency or an independent audit firm to monitor the operation of the 
markets executing on the PAS 140. This function allows the surveillance body to determine 
whether the execution of an auction conforms to norms and, optionally, to intervene in the 
market when deviations are detected. 

MAC 150 consists of a computer running a computer program that enables a market 
operator, an entity housing the PAS 140 and responsible for the operation of the PAS, to 
monitor the execution of various markets operating on the PAS 140. MAC 150 also 
administers registration transactions, such as the process whereby traders identify themselves 
to the system (e.g., providing their names and credentials). Additionally, MAC 150 allows 
market operators to troubleshoot the system in real time. 

PAS 140 includes a computer that runs a computer program that may accept multiple 
market protocols submitted to it from an MSC 1 10 and execute multiple market protocols 



(e.g., opening auctions, admitting or rejecting bids, clearing prices, notifying traders of market 
events, and closing auctions). More specifically, PAS 140 employs several modules to control 
the market operation. Modules such as bid verifier, release information manager, and clearer 
assist in managing the market by processing incoming bids, responding to queries, maintaining 
market state (e.g., tracking bids, etc.), and reporting results to traders and optionally to non- 
traders. Through these modules, various transactions may be performed such as bid 
verification (e.g. does a bid from a trader qualify as a "bid" under the rules), release of 
information (e.g., show all the current bids), a clear (e.g. clear the prices or bids), registration 
of information (e.g. name and phone number of the trader), and a bid transformation. In the 
preferred embodiment, various components are organized into a complete system through a 3- 
tier architecture bounded by double firewalls 164 as shown in Figure 1A. 
The Market Specification Console (MSQ 

MSC 1 1 0 makes available to a market designer a full spectrum of rules for defining market 
protocols in an intuitive fashion. These rules may be modified by the market designer. 
Combinations of rules for participating in and operating a market constitute market protocols. 
Market protocols specifiable through MSC range from simple auctions such as English, Dutch, 
and sealed-bid auctions, to highly complex auctions such as those conducted on the trading floors 
of financial exchanges and the California Power Exchange. 

Table 1 provides examples of some types of auctions that could be specified through 
MSC 1 10 for deployment in PAS 140. As shown below, auction types may be arranged in a 
hierarchy, which the market designer would use as part of the market specification process. Note 
that the partial hierarchy depicted is but one of many possible arrangements. 
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Table 1: Example of Auction Classifications 



1) 


Single good type 




a) One-sided (e.g., only buyers bid) 




i) English (ascending price) 




ii) Dutch (descending price) 




iii) Sealed-bid 




b) Two-sided (buyers and sellers bid) 




i) Continuous double auction 




ii) Call market 


2) 


Multiple good types 




a) Simultaneous ascending price 




b) Combinatorial (bundle bidding) 



Table 1 shows multiple classes of auctions. The table includes auctions for one good or 
multiple goods. Single goods may be auctioned by one-sided or two-sided auctions. Among the 
types of one-sided auction are English, Dutch, and sealed-bid auctions. The English auction (in 
the case where buyers bid) operates in the typical fashion wherein Trader A makes a bid on a 
good. Trader B would then make a bid that is higher than the bid submitted by Trader A. The 
highest bidder prevails in the buy-side English auction. In a buy-side Dutch auction, on the other 
hand, prices start at a high level and decrease until a trader submits a bid. The sealed-bid auction 
involves collects bids from traders and withholds information until the end. At clearing time, the 
best bids prevail. 
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Two-sided auctions represent another class of auction. In two-sided auctions, both 
buyers and sellers submit bids. One example of this class is the continuous double auction. A 
continuous double auction collects offers from buyers and sellers. If an offer to buy and an offer 
to sell match, a trade is consummated. A call market operates similarly, except that bids are 
aggregated over time, and matched in a periodic manner. Trades typically occur at a uniform price 
consistent with all of the matched bids. 

As noted above, multiple goods may be auctioned. This involves multiple goods offered 
by a single company, a government agency, or some other entity. Simultaneous ascending price 
auctions involve multiple ongoing auctions for different goods. Combinatorial (bundle bidding) 
auctions involve traders bidding for combinations goods such as a trader submitting bids for the 
bundle consisting of good A, good B, and good C. 

Generally, a market designer may define a market in one of two ways. One method is to 
select a market protocol that has been predefined in parameterized form, and input the values of 
its free parameters. For example, a market designer may specify the minimum increment and 
start time in an English auction. The other method is to allow a market designer to define 
arbitrary market protocols suited to any given situation. 

Although the number of market protocols is limitless, some universal principles apply. 
First, every auction is associated with a set of entities that are allowed to participate, called 
traders. Traders participate in markets by submitting bids, which are offers to buy or sell the 
auction's goods at specified terms (e.g., prices and quantities dictated in the bid). As a result of 
the bids, some information may be released to traders about a market's status. Under conditions 
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specified in the market protocol, the auction clears and the resulting exchanges are determined. 
The auction closes when a termination condition is met. 

Because of these universal elements, it is possible to define TPs that represent particular 
choices for features of a market protocol, applicable across a range of auction types. For 
example, one TP might specify whether an auction is one-sided (e.g., buyer or seller bid), two- 
sided (e.g., buyer and seller bid), a sealed-bid or "open outcry" (e.g., bids are exposed to all 
traders). TPs may also dictate when important events, such as clears or information releases, are 
to occur. Further examples of TPs and how they are used to specify auction behavior are 
presented in the section describing the PAS 140 below. 

Each phase of an auction is thus defined by specifying the TPs it comprises or the 
timeline for application of the TPs. One general method of specifying a time line is to invoke a 
scripting language that has control constructs for sequencing and iteration, access to internal 
auction events and a time-of-day clock, and the capability to call the TPs. This role may be filled 
by a specially designed auction scripting language, a standard scripting language such as TCL/TK, 
JavaScript, a full-fledged programming language such as Java, any other scripting, or any 
prograrnming languages. The preferred embodiment of the invention utilizes a script generator 
121 to generate scripts in a language generically referred to as CommerceScript. CommerceScript 
is a temporal protocol script that represents an auction specification. 

The temporal nature of CommerceScript provides an additional level of convenience in 
market specification. Rather than restrict the market designer to textual scripting, the invention 
presents to the market designer a visual scripting option. This visual scripting option allows the 
market designer to graphically draw a time line and place along the time line various TPs. Each 
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TP may be annotated with a variety of information such as the market entity executing the TP, 
whether this execution is mandatory or permissible, whether conditions must precede or occur 
after this step and temporal preconditions that must be met. The output of the visual 
specification component is similar to that of a textual specification component. Although various 
visual programming tools exist in the art, such tools have not been applied to the creation of a 
trading market specification. One novel aspect of the visual specification component annotation 
involves processing steps as "mandatory" or "permissible which is unique to the commercial 
application. 

The Programmable Auction Server (PAS) 

PAS 140 is extensible and flexible. PAS comprises an interpreter for CommerceScript, 
and modules implementing the behaviors dictated by the TPs referenced in the script. In 
principle, there is no bound on the range of allowable market protocols, other than the pragmatic 
limitations of the PAS 140 in terms of computer memory and other computational resources. 

A market protocol may accord to distinct market entities various permissions to perform 
activities such as bidding in certain ways or retrieving certain forms of information. Such 
permissions are based on registered trader and auction attributes as captured by the MAC 150 
registration process. One feature of the PAS 140 is its generic way of handling permissions 
regardless of the particular market protocol that is executed. Each step in the execution of the 
protocol is gated by the type of market activity, its particular instantiation (i.e. 9 the value of 
specified inputs), and the entity attempting to execute it. Flexibility permission management 
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offered by the invention is important in industrial applications that generally require security 
measures such as defenses against malicious infiltrators and incompetent market entities. 

To promote fault tolerance, the PAS 140 creates an audit trail by logging every activity 
that takes place on the system, including bids, other trader actions, market clear results, and other 
similar actions. In addition, a trade management module records trades and the obligations 
incurred by each participant. For example, the trade management module may record that Trader 
A, a buyer, submitted a bid of $100 for a good such as a book. Because this bid reflects the 
highest bid received, Seller B sold his book for $100 to buyer A. Trade management module will 
record that buyer A is obligated to pay Seller B $100 in exchange for Seller B's book. 

PAS 140 is comprised of several modules that may be added or customized for different 
market protocols. These modules, discussed below, implement market functions based on TPs 
specified by the market designer. PAS 140 uses script interpreter 141 to execute the market 
protocol, and provides application program interface 510 and proxy bidder 509 for extensibility 
and connection with other auction system components. 

1. Script Interpreter 

PAS 140 uses a generic script interpreter 141 that is capable of recognizing and 
interpreting CommerceScript, other type of script, or any programming language. Additionally, 
script interpreter 141 may be modified to adapt to new scripting languages. 

2. Bid Verifier 

Bid verifier 151 tests each incoming bid for consistency with the bidding rules established 
by a market designer. A "bid" is defined as an expression of an action that may modify a bid 
state. Bids include a variety of actions such as a buyer indicating a willingness to purchase a 
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good at a certain price, or a withdrawal of a previous bid. Changing a bid qualifies as a new bid. 
If verified as an eligible bid, the bid is admitted to an order book; otherwise, the bid is rejected. 
There are many possible varieties of bidding rules that may be specified in TPs through the MSC 
1 10. Examples of bidding rules provided below are for illustrative purposes only. 

5 In one embodiment, bid verifier 151 operates such that the incoming bid is compared to a 

bid referred to as a base bid. The base bid may refer to the trader's own bid, to all bids, or to 
some summary (e.g., a price quote), as determined through applying me bid rules. For example, 
assume a bidding rule requires that in order for a bid to be eligible, a bid must meet the following 

I; 3 requirement: 

ljOj bid > highest bid received + x 

1 1 wherein x equals $20 and the highest bid received is assumed to be $ 1 00 and it is the highest bid 
i I received for that auction at a certain period of time. The highest bid represents the base bid. In 
1 1 this example, the base bid is replaced with a higher bid. The higher bid is then referred to as the 
i j base bid. The incoming bid must be at least $ 1 20 to be entered into the order book. 
¥§ Another example of a bidding rule may restrict the type of traders who are eligible to bid 

or it may restrict the bids that different traders may submit. Bidding rules may also regulate 
whether withdrawals or replacement of a bid are allowed. Limits may also be placed on the 
frequency of such actions, or of bids in general. Any bidding rule may be designated by a market 
designer to apply over the entire course of the auction or for designated periods (e.g., stages or 
20 rounds). Dynamic bidding rules based upon bid content may also be used. For example, 

ascending (or descending) restrictions dictate that replacement bids must exceed or be exceeded 
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by some base bid, as discussed above. These restrictions may apply to only one side of a trade 
or to both buying or selling. 

In other ways, bidding rules may serve to define what offers are expressible. For 
example, they can designate whether bids may refer to only a single unit of a good versus 
allowing bids for multiple units. Additionally, if multiple units are allowed, the bidding rules 
may designate that offers may include single price points, multiple price points, or only 
quantities at a given price. Other examples of expressivity restrictions include discrete offers 
versus continuous offers, price-quantity monotonicity, divisibility (all-or-none bidding), 
interpolations/extrapolations, etc. 

Expressible bid conditions also may be used in bidding rules to restrict bids in an auction. 
For example, expressible bid conditions include minimum quantities of a good to be bid upon or a 
minimum bid amount that must be satisfied. In regard to multi-dimensional auctions, 
combinations may be deemed permissible in bundles. "Portfolio" bidding may also be acceptable. 
Maximal complexity of bundle constraint specification may also be included. 

Bidding rules regarding eligibility also may be specified. Eligibility of a trader or a 
particular bid may be specified in a variety of ways. For example, the eligibility of a trader or a 
bid may be specified in terms of previous auction history, including the history of auctions 
distinct from but related to the auction in question. This is typically the case for restrictions 
referred to as activity rules that are common in complex auction scenarios. 

Bidding rules may also involve payments, such as a fee paid in order to allow a 
participant to engage in trading. For example, an initial bid may require an entry fee (refundable 
or not refundable), or withdrawals may be allowed on payment of a decommitment penalty. The 
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foregoing represents a portion of bidding rules that may be used in an auction. By executing of 
bidding rules such as those presented above, a "bid state" is created. A "bid state" is the status 
of the bids from the various traders. The status of bids is maintained in a fashion that is known 
in the art. A bid state also may include historical data of the various bids. For example, a 
graphical representation of bids may be displayed to traders on a trade interface displayed to 
traders. Through the trader interface, a trader is capable of inputting and receiving information 
from the universal auction system. Information may be communicated to the universal auction 
system through a keyboard, a touch screen display, or voice activated system. 
3. Bid Transformer 

A bid transformer 155 implements discriminating allocation market protocols that may 
produce different effective prices. Discriminating allocation market protocols may be based upon 
the identity of the trader ("trader identity") submitting the bid, the quantities allocated to a trader 
identity, or any other condition that the market designer designates. Trader identity may be 
associated with individual traders or established groups (e.g., certified dealers, registered clients, 
holders of particular credit ratings). 

In the preferred embodiment, each submitted bid is subjected to a bid transformer 155 
that applies a discriminating policy to a bid. For example, if a particular trader such as Trader A 
is entitled to a discount of 20%, its offered price is increased by an amount such that reduction 
by 20% equals the original bid. Accordingly, a bid of $10 by Trader A is transformed to $12.50. 
This transformed bid of $12.50 is then compared to the bids received by other traders. 
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Another example relates to offered prices for quantities of goods (or services such as 
amounts of specified tasks) above a certain threshold amount. Quantities of goods may be 
assessed a "penalty" percentage to bias the allocation toward a trader(s). After the bids are 
transformed by bid transformer 155, the transformed bids are sent to the bid verifier 151. 

5 One alternative method to the preferred method involves implementing a discriminating allocation 
policy using the clearer 154. In this approach, bids are not transformed. Instead, the clearing 
calculation is modified to implement the discriminating allocation policy. For example, if the 
discriminating allocation policy dictates that no trader should receive more than half of the 

r i allocated quantity, the clearing algorithm would maximize its objective measure subject to the 

ljoj constraint that this quota is not exceeded. 

y 4. Information Manager 

^ Information manager 152 controls the information released by the auction to participants 

I ^ during the course of bidding. In effect, it dictates the class of queries regarding bid state and 
I j bidding and trading history that an auction may handle. Unhandled queries produce null 
V9 responses. 

Mechanisms may distinguish between information available through active and passive 
means. Traders may actively request released information through explicit queries. Information 
is released to passive access by defining a price quote operation. A price quote is a particular 
form of auction status summary that typically specifies a result of a hypothetical clear, but may 
20 also specify any other salient information (e.g., the highest buy bid received). A price quote may 
be computed at a release time and cached so that information may be made available without 
querying and explicit queries do not induce a complex calculation. For single-good auctions, one 
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form of price quote is a "bid-ask spread" that may degenerate into a single price. A bid quote 
represents a price at or below which an agent would have to offer to sell in order to successfully 
sell (assuming no other changes occur to the auction state). An ask quote represents a 
corresponding price with respect to an ask quote. Auctions may define multiple price quote 
operations to be employed in different situations or for different classes of traders, where class 
may be characterized in terms of trader identity or bid status. 

The market designer defines the behavior of information manager 152 by selecting TPs 
(through MSC 110) specifying the content and timing of price quotes, as well as the class of 
explicit queries to be handled. Like other auction events, information releases may be timed 
according to fixed schedules or by events {e.g. clears, bids, inactivity intervals, etc) 

In addition to the bid state as reflected in the order book 154, the information manager 
152 may also control release of other relevant auction state information. For example, the auction 
state may include the eligibility of traders to make additional bids, or other market information 
that may affect trader's expectations. 

The information release policy implemented by information manager 152 can have a 
significant influence on the nature of the auction. Moreover, at one extreme, all information about 
the bid state information may be revealed, as in an outcry auction. However, at the other 
extreme, if a sealed-bid auction is used, no information is revealed about other traders' bids. 

5. Order Book/Clearer 

Order Book/Clearer 154 ("clearer") determines an allocation of goods and terms of 
exchange on the basis of bidding history and auction rules. An allocation typically corresponds 
to a set of trades among the auction participants. Once the trades are determined, it reports the 
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results to traders and, optionally, non-traders. Clearer 154 uses the bid state as represented by 
the order book to derive the exchanges determined by auction rules in a given state. It may also 
invoke a trade manager module to control the notification and execution of these trades. 

Clearer 154 is invoked according to the temporal flow TPs specified in the MSC. Other 
TPs dictate how it determines an allocation. An allocation policy may be specified by naming 
the algorithm implementing the function from the auction state to allocations, or by defining a 
complete set of criteria for selecting among the possible allocations (e.g., allocations consistent 
with the offers represented by bids). 

Clearer 154 may use a general class of allocation policies that may be defined by 
interpreting the offers specified in bids as if they represent value functions, and maximizing the 
resulting surplus. However, this maximization is generally not unique because monetary 
transfers are zero-sum operations. Thus, the rules may need to specify how to allocate surplus 
among traders. For example, in a sealed-bid auction of a single unit of a good, the lst-price 
auction maximizes total surplus and then allocates as much as possible to the seller. The 2nd- 
price auction allocates as much of the surplus to buyers. A k-double auction may divide this 
surplus fractionally according to parameter k. Typically, even these rules are not unambiguous, 
since there may be a choice among buyers (or sellers) to allocate a positive surplus. Methods for 
choosing among surplus-equivalent bids might be based on features such as time of bid, 
quantities, or even random selection. Such criteria are often referred to as tie-breaking rules. 

Clearer 154 may use another type of clearing policy that determines exchanges based 
upon chronological priority. For example, the continuous double auction ("CD A") matches 
buyers and sellers instantaneously upon receiving compatible offers. The release of information 
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about the exchange may be delayed. In contrast, a call market aggregates bids over time before 
determining an allocation. As the clearing interval of a call market is reduced, an approximate 
CDA is determined. 

Clearer 154 may use discriminatory or non-uniform-price auctions that may allocate 
5 identical goods to traders at different prices. For example, in pay-your-bid auctions, successful 
traders on one side exchange for exactly the amount they bid, regardless of terms for other 
successful traders. 

Regardless of the allocation policy specified, the invention is capable of realizing each by 
I: i allowing a market designer to specify an available TP or integrate an entirely new component into 
lj&f PAS 140 to supplement the policy. 
1 1 6. Proxy Bidder 

"I Bids submitted by a trader may be entered by direct bidding or proxy bidding. In direct 

I \ bidding, the bidder selects an auction and enters a bid using the computer keyboard and mouse 
{ j (interface provided by UTC 120). In proxy bidding, the user defines a script that bids on his or 
1$ her behalf in one or more auctions running on the PAS 1 40. As part of the proxy bid, a trader 
also specifies whether the script is to run within the trader console UTC 120 (e.g., proxy bidder 
508), or be transmitted to the PAS 140 and run there (e.g., proxy bidder 509). 

The proxy bidder 509 may be further optimized to exploit the fact that it is running 
within the PAS. Specifically, when there are proxy bids from multiple traders, the proxy bidder 
20 509 may resolve the competition among these bids directly, avoiding the need to iteratively 
submit progressively increasing bids to the order book. 
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7. Application Program Interfaces 

PAS 140 has a set of Application Program Interfaces ("APIs") 510 that provide a means 
for extending the PAS to incorporate replacement or additional modules. The purpose of the 
APIs is to turn a closed system to an open system. A closed system requires that the system be 
used in total or forego using the closed system. In an open system, components may be 
integrated seamlessly with existing components. For example, APIs allow integration of PAS 
140 with (1) legacy software for registration or transaction management; (2) auditing or 
monitoring functions of accreditation agencies, (3) programs implementing novel clearing 
algorithms, and (4) programs performing trades which bypass the UTC 120 discussed below. 

The Universal Trading Console (UTC) 

The UTC 120 has at least two functions-display of information and bid input. Examples 
of information displayed to a user include activities on the PAS 140 and ancillary information. 
PAS 140 activities are, in principle, events logged by the PAS 140, such as the start of an 
auction, the bids placed, and the prices cleared. Actual information displayed may vary from one 
market to another, reflecting the different market designs. In particular, the amount of 
information displayed may vary. For example, two simultaneous ascending-bid auctions may 
vary the information disclosure policy with one auction releasing information after each round 
such as the entire list of bidders and their bid in that round, whereas another auction may release 
only the aggregate bids supplied with no bidder-specific information. Ancillary information may 
be any information that is relevant to making trade decisions but that is not inherent in the market 
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activity. For example, in energy markets and many other futures markets weather forecasts may 
be important information to a trader. 

Diversity exists in the format of both the information dissemination and the bid collection 
among different types of auctions. In the preferred embodiment, this diversity is accommodated 
by introducing a database layer between the PAS 140 and the UTC 120. For each auction type, 
several specific database schemas must be introduced. The PAS 140 populates the database with 
specific data and that data is displayed in the UTC 120 automatically using dynamic HTML. A 
feature of this design is that while the database tables in the PAS 140 must be created for the 
particular auction, the UTC 120 requires no modification. 

Figures 2 and 3 schematically show one embodiment of the invention in which several of 
the modules are shown. Here, a bid (e.g. $100) is submitted by Trader A at operation 600. The 
bid is sent to the bid verifier 151 at operation 610. Bid verifier 151 receives the bid and uses the 
bid by incorporating the bid in the TPs set by the market designer. At operation 610, the bid 
verifier determines whether the bid is acceptable. If the bid satisfies the minimum standards for 
an acceptable bid established by the market designer, the bid is verified as an acceptable bid and is 
placed into the order book/clearer 154 at operation 640. If the bid fails to meet these minimum 
standards, the bid is rejected and Trader A is notified that his bid is unacceptable. Information 
manager 152 notifies Trader A by transmitting the rejection to Trader A at operation 625. 
Similarly, proxy bidder 509 may also submit a bid to the bid verifier 151. This bid undergoes the 
same process as listed above. The trader(s) who submitted the proxy bid is notified through the 
information manager 152 as to whether the proxy bid is acceptable or is unacceptable. 
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The Universal Surveillance Console (TJSC) 

Professional trading markets are generally associated with one or more surveillance bodies 
such as the SEC, the FCC, FERC, California Public Utility Commission (CPUC), internal 
monitoring departments of exchanges, and external private audit agencies. A surveillance body 
monitors trading activities and ensures that trading activities comply with specified standards. 
Monitoring is essential to ensure that traders comply with laws or rules. Compliance with rules 
promotes faith in the market USC 130 presents information from the marketplace to a 
surveillance agency. While the USC 130 does not provide ways in which to trade in the market, 
it does provide market controls that are not provided to traders. Examples of such controls are 
broadcasting messages that appear on UTCs 120 and halting trading activity. 

Three-Tier Architecture of the Preferred Embodiment 

The system of the present invention is designed to adapt to the needs of a variety of 
different types of trading markets. Operating on a wide range of hardware, from single-user 
personal computers (PCs) to integrated client/server based platforms, the system of the present 
invention is well suited to a small number of users and to a market with thousands of users. The 
system may be field-modified to handle an increasing number of users as market requirements 
mature and change. 

Figure 4 shows data flow of one embodiment of the invention. A market 700 comprises 
an auction 710. Although a market may include a plurality of phases, only one phase is shown in 
operation 720. With respect to a plurality of phases, one skilled in the art will appreciate that an 
auction specification of one phase may be replaced with an auction specification of another phase 
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by methods known in the art. A bid 5 submitted by a trader, is sent to the bid verifier at operation 
730. The bid verifier determines whether the bid meets certain rules that are specified by a 
market designer or another party who may control an aspect of the auction. Thereafter, an 
admitted bid is sent to the bid transformer at operation 740. At this operation, the bid is 
modified to reflect discrimination policies wherein the bid may be increased, decreased, or some 
other modification in order to reflect a status that has been granted to that particular trader or to a 
particular good. At operation 750, the bid is processed wherein rules are applied to the accepted 
bids and the best bid prevails. Note that the best bid may not necessarily be the highest bid; 
rather, it is the bid that reflects the discrimination allocation policies that are applied. The bid is 
then submitted to the order book at operation 760. At this operation, tie breaking rules may be 
applied, sort criteria may be used, and any other criteria designated by the market designer may 
be implemented. At operation 770, the bid is submitted to the clearer wherein a clearing 
operation is applied. At operation 780, the bids are submitted to the trade manager for further 
processing. Information manager is continuously operating and may be providing information to 
traders on a continuous basis at operation 790. 

Figure 5 shows one embodiment of the invention wherein a three-tiered architecture 
supports scalability allowing other system architectures to be implemented. A first tier 110 
includes a front-end database 1 12 and Web applications running on Web server(s) 1 1 1 that 
constitute the interface between the users 1 14 and the back-end 116 of the system. Authorized 
users may access the system through a Web browser. GUI may be run either as a Java Applet or 
as a common HTML (depending on the user's choice and browser version). Java and HTML 
programming languages are well known to those of ordinary skill in the art. To secure the 
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system, the Web application is surrounded by a firewall 122 in a DMZ (Demilitarized Zone) 
configuration making it almost impossible to penetrate the application server(s) 120. The 
application's logic constitutes the second tier 1 15. The middleware 130 environment is 
component-based allowing high-availability and scalability. The third tier 133 contains the 
database 136 and the interface 138 to a market administrator's legacy systems. Note that 
because the output of the auctioning process is being polled by a legacy system, the full security 
of the legacy environment is assured at all times. 

Thus, a method and apparatus for designing and deploying a universal, interactive, real- 
time, trading market system serving traders communicating via the Internet is disclosed. 
Although the present invention has been described with reference to specific exemplary 
embodiments, it will be apparent to those of ordinary skill in the art that various modifications 
and augmentations may be made to these embodiments without departing from the broader spirit 
and scope of the present invention as set forth in the following claims. 
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CLAIMS 



We claim: 

1 1 . A universal auction system having a programmable auction server, the programmable 

2 auction server comprising: 

3 a plurality of auction modules wherein at least one auction module corresponds to at least 

4 one function of an auction selected from the group consisting of a bid verifier, an 

5 information manager, a clearer, a registration manager, and a proxy bidder. 

;tj 2. The programmable auction server as in claim 1 , further comprising: 

J2| auction modules wherein at least one auction specification module performs at least one 

&j transaction selected from the group comprising a bid verification transaction, an information 

% management transaction, a clearing transaction, and a registration transaction. 

h i$ 3 . The programmable auction server as in claim 1 , further comprising: 

2 a set of trading primitives; 

3 a script interpreter for interpreting a temporal protocol script representing an auction 

4 specification, the script including references to at least a portion of the set of 

5 trading primitives; and 

6 means for switching an auction specification of one phase with an auction specification of 

7 another phase. 
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4. The programmable auction server as in claim 3, wherein at least one auction module of one 
phase is replaced with at least one auction module of another phase. 

5. The programmable auction server as in claim 1 , at least one phase comprising an interval 
in which at least one transaction occurs, the transaction is selected from the group comprising 
submitting a bid, admitting a bid, withdrawing a bid, and replacing a bid. 

6. The programmable auction server as in claim 5, wherein the phase is terminated by a 
condition. 

7. The programmable auction server as in claim 6, wherein the condition is a time period. 

8. A universal auction system comprising: 

a trading primitive; 

a script generator for translating trading primitives to temporal protocol script; 
a script interpreter for interpreting script protocol; and 

a market specification console adapted to support a plurality of market 
protocols. 

9. The universal auction system as in claim 8, the market specification console further 
comprising a plurality of rules wherein at least one rule is user-modifiable. 

10. The universal auction system as in claim 9, wherein rules comprise market protocols. 
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11. The universal auction system as in claim 8, wherein the market specification console is 
coupled to a programmable auction server wherein said programmable auction server is adapted 
to receive market protocols from said market specification console, the market specification 
console having a graphic user interface (GUI). 

1 2. The universal auction system of claim 1 1 , wherein a trader interface is coupled to a 
network. 

13. The universal auction system of claim 12, wherein the trader interface is used by a trader 
to submit a bid. 

14. A market specification console comprising: 

means for specifying a plurality of market protocols; 
means for displaying at least one market protocol; and 

means for transmitting at least one market protocol to a programmable auction server. 

15. A method of designing a universal auction system comprising: 

generating a plurality of auction modules wherein at least one auction module corresponds 
to at least one function of an auction selected from the group comprising of a bid verifier, an 
information manager, a clearer, and a registration manager; 

specifying a plurality of rules wherein a transaction comprises at least one rule; and 
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6 implementing at least one transaction comprising a bid verification, information 

7 dissemination, clearing, and registration of information. 

1 1 6. The method of claim 15 further comprising: 

2 displaying a rule to a market designer. 

1 17. The method of claim 1 5 further comprising: 

2 modifying at least one rule. 

1 18. The method of claim 1 5 further comprising: 
interpreting a scripted rule. 

J] 19. The method of claim 1 5 further comprising: 
21 generating a scripted rule. 

=1 20. The method of claim 1 5 further comprising: 

H: 

=2j transmitting a rule to a programmable auction server. 

1 21. The method of claim 1 5 further comprising: 

2 maintaining a status of bids. 
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ABSTRACT 

A universal auction specification system including a network-accessible set of trading 
primitives ("TPs") and a script generator for combining the set of TPs into a temporal protocol 
script representing a particular auction specification. The system further includes a 
programmable auction server that has a plurality of modules wherein each module may have a 
TP. 



30 




Fig la 



PAS 
140 







SCRIPT INTERPRETER 141 








BID VERIFIER 151 










BIDtRANSFQRMER 155 










INFORMATION MANAGER 152 








ORDER BOOK/CLEARER 154 








PROXY BIDDER 5Q§ 








APPLICATION PROGRAM INTERFACE 510 









Fig. lb 



PAS 140 



510 




BID VERIFIER 
151 



INFORMATION 
MANAGER 152 



I 



ORDER BOOK/ 
CLEARER 154 



I 



SCRIPT INTERPRETER 



141 



Fig. 2 



BID IS SUBMITTED BY A 
TRADER 



I 



BID VERIFIER DETERMINES 
WHETHER THE BID SATISFIES 
RULES SET BY A MARKET 

DESIGNER gio 



DOES BID SATISFY 
BIDDING RULES 
SET BY A MARKET 
DESIGNER? 



.NO- 



NOTIFICATION THAT BID HAS 
BEEN REJECTED. THE 
REJECTED BID MAY BE POSTED 
TO THE PARTIES (E.G. TRADER A) 



NOTIFICATION THAT BID HAS 
BEEN ADMITTED. THE BID IS 
POSTED TO PARTIES 
(E.G. TRADER A) m 

+ 

BID IS PLACED INTO THE 
ORDER BOOK 

64Q 



Fig. 3 



o 

5 

o 



> 
m 

JO 




IE 
> 

CO 





t 



Attorney's Docket No.; nfttfftftppQlX 

DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 

Ag a below named inventor, I hereby declare that 

My residence, post office address and citizenship axe as stated below, next to my name* 

I believe I am the original, first, and sole inventor (if only one name is listed below) or any original, : tot* and 
joint inventor (if plural names are listed below) of the subject matter which is claimed and for which s patent is 
sought on die invention entitled 

A METHOD AND AN APPARATUS FOR A UNIVERSAL TRADING MARKET DESI GN 

AND DEPLOYMENT SYSTEM 



the specification of which 



a 



is attached hereto, 
was filed on. 



as 



United States Application Number 

or ICT International Application Number 
and was amended on 



(ifipliubfe) 

I hereby state tfaat I have reviewed and understand die contents of the above-identified specification, iicluding 
1 the claimfi), is amended by any amendment referred to above. I do sot know end do not believe that the 

claimed invention was ever knows or uaed in the United States of America before my invention thereof, or 
"i patented or described m any prated poblicatton in any cani^ 

year prior to this application, that the lame was not in public use or on sale in the United States of An erica 
J more than one year prior to this application, and that the invention has not been patented or made *e iwbjeot 
* an inventor's certificatB issued before the date of to applied many country tora^ 
I America on an application filed by me or my legal representatives or assigns more than twelve month i (for a 
I utffity patem application) or aix inontlu 

I acknowledsj the duty to disclose all information known to me to be material to patentability as defin ed in Title 
, 37, Code of Federal Regulations, Section 1.36. 

' I hereby claim foreign priority benefits under Title 35, United States Code, Section U9(aKd), ofay foreign 
application(s) for patenter inCeator's certificate listed below and have ako identified below any foreign 
j a| pSon f or patent or inventor 1 ! certificate having a filing date before that of the application on wm ch priority 
i is claimed: 

J vAnrV™*™ ApplicationftV. 



APPLICATION 
NUMBER 


COUNTRY (OR 
TNTi^TBIPPCm 


DATE OF FUNG 
rdav. month. Year) 


PRIORITY CLAIMED 








□ No DYes 








□No DYea 








□ No DYes 



! hereby daim the benefit under True 35, United State; Code, Section 119(e) of any United States pprvisianal 
application(s) listed below: 



AWUCATTON 

NUMBER 


HLINODATE 











Docket No. 00366O.POO1X 



Pg 1 



I hereby claim the benefit under Tide 35, United States Code, Section 120 of any United States application^) 
luted below and, insofar** the subject naatrer of each of the claims of this application Is not disclosed in the 
prior United States application in die manner provided by the first paragraph of Tide 35. United State s Code, 
Section 1 12, 1 acknowledge the doty to disclose all information known to me to be material to patent* biUty as 
defined in Title 37, Code of Federal Regulations, Section 1.56 which bocame available between the filing date of 
the prior application and the national or PCT international filing date of this application: 



APPLICATION 
NUMBER 


FILING DATE 


STATUS (ISSUED, 
PENDING, ABANDONED) 





















I hereby appoint BLAKELY, SOKOLOFF, TAYLOR & 2AFMAN, a firm inrtnritng: William E. A ford, 
Reg.37,764; Farad E. Amini, Reg. No. 42,261; Amy M. Armstrong. Rea. No. 42£65; Ajoyrios :.\ C. 
AuYcong, Reg. No. 35,432; William Thomas Babbitt, Reg. No. 39,591} Carol F. Barry, Reg. No, 41,600; 
Jordan Mchall Becker, Reg, No. 39,602; Bradley J. Berexnak, Reg. No. 33,474; Michael A. Benujdfcoo, 
Reg. No. 35,934; Roger wTBlakely, Jr., Reg. No. 23,831; Gregory D. Caldwell, Reg. No. 39,92<.; Yong S. 
Choi, Reg. No. 43,324; Thomai M. Coeiter, Reg. No. 39,637; Michael Anthony DeSanctis, Reg. No. 
39,957; Daniel M. De Vos. Reg. No. 37,813; Robert Andrew Diebl, Reg. No. 40,992; Tarek N. Fahnu, Reg. 
No. 41,402; James Y. Go, Reg. No. 40,621; Dinu Garia, Reg. No. 42,996; David R. Halvorsoa, He* No. 
33,395; Thomas A Hassing, Reg. No. 36,159; James A, Henry, Reg. No. 41,064; Willmore F. Holbrow 
HL Reg No. 41,845; George W Hoover II. Reg. No. 32,992; Erie S. Hyman, Reg. No. 30.139; Dt* H. 
Jobttseo, Reg. No. 36tf£ William W. Kidd.W No. 31,772; Michael J. MaUje, Reg. No. 36,5!>1; Ptafl 
A. MendoniaTReg. No. 42,879; Damn J. MUliken, Reg. No. 42,004; TWnh V. Nguyen, Reg. No 42,034; 
Kimhedey G. Nobles. Reg. No. 38,255; Bftbak Rjdjaian, Reg. No. 42,096; JatneaH. Salter, Reg. No. 
35,668; William W. Scbasl, Reg. No. 39,018; James C. Senefier, Reg. No. 31,195; Anand Sethjtfiman. Reg. 
No. 43.351; Charles E. Shemwell, Reg. No. 40,171; Jeffrey S. Smith. Reg. No. 39,377; Maria McComack 
Sobrino, Reg. No. 31,639; Stanley W. Sokotoff, Reg. No. 25,128; Judith A. Szupesi, Reg. No. 35,393; 
Vincent P. Tassinari, Reg. No. 42,179; Edwin H. Taylor, Reg. No. 25,129; George G. C Tseng, Reg. No. 
41,355; Joseph A. Twarowski, Reg. No. 42,191; Lester J. Vincent, Reg. No. 31,460; John Patnck Ward, 
Reg. No. 40,216; Stephen Waihola, Reg. No. 43,237; Charles T, J. Weigea, Reg. No. 43^98; Kiik D. 
Williams, Reg. No. 42,229; Steven D. Yates, Reg. No. 42^42; Ben J. Yorks, Reg. No. 33,609; «4 
Norman Zafman. Reg. No. 26,250; my attorneys; and Edwin A. Sloane, Reg. No. 34^728; my pate: it agem, 
with offices located at 12400 Wilshire Boulevard, 7th Floor. Los Angeles, Caufonua 90025, telephc neplO) 
207-3800, with full power of substitution and revocation, to prosecute tins application and to transact all 
business in the Patent and Trademark Office connected herewith. 



I harebv declare feat all statements made herein of my own knowledge are true and (hat all statements madeon 
information and belief ate believed w be tr^ 

that willful false statements and (he Eke so made are punishable by fine or imprisonment, or bom, an Jer 
Section 1001 of Title 18 of the United Sates Code and that nil* willful false flatenietitt 
validity of the application or any patent issued tberoon 



full Name of Sole/First Inventor (£iwn name, family nime) 



Inventor's Signature 
Residence Palo Alto, Calif bnaa 




(City. 

P. O. Address #58 Qnw Street 



paoAlto, California 94306 USA 

Docket No. 003660.P001X 



Yoarr Shoham 



Tux. 01 1*> 

Qtizaiship Israel 



(Country) 



Pg 2 



Full Name of Second/Joint Inventor (given nunc family oime) Michael Welhnan 

Inventor's Signature /U^C^P ft&JJL^ Date 2^ Tu^ $j 
Residence Ann Arbor, Michigan m Gdzcnship US 

(City , Stat*) (Country) 

P. 0. Address j27 Riveryjgw Pr 

Ann Aibor, Michigan 48104 USA 



Full Name of Third/Jofat4^^ foully nam*) EUhan Ephratt 

Inventor's Signature ^ ^/ W Date 0? Vj^h 

Residence Sunnyvale, California m Qtizenship TsrasI 

(City , Sw<) (Country) 

P. 0. Address lyKTenak* Place Ant C-3 >„ „ 



Sunnyvale, CaKfarrda 94087 USA 



Full Name of Fourth/Joint Inventor (glvtn nime, imuiy nun*) 



Inventor's Signature ^^^^^^^^^^^^^^^^^^ Dato 



Residence . Ci t lJflns hip ________ 

fCiVy t ftfl#) {Country) 

P. O. Address , ____ 



Full Name of Fifth/Joint Inventor (given name, fcmiiy i 

Inventor's Signature Date 

Residence , Qrifleaahip _ 

(Qn i Sta«) (Country) 

P. O. Address 



Docket No. 00366OF0O1X 



